The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Telecommunications service providers and equipment manufacturers are rapidly developing and deploying packet-switched data communication networks that can carry voice and telephone call and signaling information, and that conform to published, non-proprietary engineering standards and protocols. Such “open packet telephony” (“OPT”) networks allow for integrating multiple services, such as voice and data, on the same network, which results in a cost savings.
The TMN (Telecommunications Managed Network) hierarchy defines five layers of management systems that may be used to manage such telecommunications networks. At each layer, there are associated management systems. Systems at the upper four layers include Business Management Systems (BMS), Service Management System (SMS), Network Management Systems (NMS), and Element Management Systems (EMS). At the network element layer, there are interfaces to the higher-level systems, usually based on established protocols (e.g., TL1, SNMP, etc.).
According to TMN standards, Network Management Systems deal with network capabilities including the managed view of the network focusing on end-to-end connectivity (and presentation of a network view to SML). Element Management Systems deal with network element data such as logs and control of managed portions of network elements, and mediation between the Network Management Layer (NML) and Network Element Layer (NEL). Network Element layer systems deal with interfaces between managing system and equipment.
The network management layer and service management layer are concerned not only with network elements (NEs), but also with higher-layer aspects that indicate how the NEs relate and what services they jointly provide. Examples are connections, such as signaling backhaul connections and MGCP control connections in packet telephony networks, or concepts such as virtual switches or virtual trunks, which comprise resources on a voice gateway and voice controller. In software management systems, entities at the NE level are represented for management purposes as network element managed objects or “NE MOs.” Similarly, entities at the network management level and service management level are represented as “service MOs.” In some cases in which a service concept or network concept is associated with the network, a service MO depends on two or more NE MOs of multiple NEs, which are related through the service MO.
A common function of management systems operating at the element management layer, such as EMSs and systems used for monitoring purposes, is auto-discovery. Auto-discovery refers to the ability of a management system to extract, on its own, certain information about what needs to be managed, rather than requiring users to provide that information. In network and service layer management, however, information is generally not deduced from the network. Instead, information about service instances comes from the service provider and is entered by the user.
Service provisioning systems are used to drive network configurations that are required to support the services into the network. In these systems, any service information is assumed to be known in advance, and is assumed not to need auto-discovery. In short, service-related management information is controlled by the service provider and not the network. To verify that a service is provisioned correctly, generally, a service provider checks whether the current configuration in the network corresponds to the configuration it is supposed to have in support of the service. Thus, the service provider determines whether the network configuration “as built” corresponds to the network configuration “as planned.” In many cases, this procedure is adequate. However, in some situations it is desirable also to discover network and service configurations, and service MOs, from the network directly, rather than depending on service-related information from other sources.
For example, assume that a service/network management and provisioning system is deployed after initial network deployment. A service provider would like to be able to see and automatically retrieve what services had earlier already been configured on the network, without needing to go through the tedious exercise or entering service MOs for the services that were already deployed. As another example, assume that a service provider has maintained poor service records, or believes that its service records are not up to date. This scenario can occur when service records do not reflect end subscribers directly, but network configurations to support certain service capacity in a given geographical area.
As another example, assume that operations personnel within a service provider's organization have bypassed service provisioning systems and provisioned service instances “by hand,” resulting in certain network-layer configuration mismatches that are hard to troubleshoot. Such scenarios apply specifically in the context of packet telephony management, where concepts such as virtual switches, signaling backhaul connections, trunk groups, or zones may be discovered, or management of metro Ethernet services, where transparent LAN services may be discovered.
In all these situations, there is a need for a way for a service provider to discover, automatically with computer assistance, what services are then actually configured in the network, or offered by the network.
There is a specific need for such a capability in packet-switched networks that carry voice. There is also a specific need for this capability in network layer management tools and service layer management tools.
Other systems and products perform some forms of network discovery but they do not address the specific needs outlined above. For example, Netsys processes configuration information from configuration files with CLI commands that are uploaded from network elements, and builds an internal data model in the form of a tree with interconnected nodes that represents the processed information. This tree can also have nodes that aggregate information across network elements, for example, across several configuration files, representing network-layer information. Subsequently, this data model can be used for provisioning or to push information back down into the network.
The iGEMS system possesses a capability to discover physical network connectivity. However, discovery is limited to physical connectivity aspects. This is believed to be done with an algorithm that encodes knowledge of how to interpret and join MIB fragments of different network elements. There is still a need, however, for an approach that is not limited to discovery of physical connectivity, but can be used to discover any type of network and service level concepts that can be derived from information in network elements.
The NEC research index available online at the domain “citeseer.nj.nec.com” includes several publications about service discovery in networks. However, that form of service discovery is different from service layer object discovery. It deals with discovering services that are offered by a particular server, which announces them to the network. Thus, its approach provides brokering of services, not service MO discovery. One example is JESA, Java Enhanced Services Architecture, utilized in advertising services in ad hoc networks. Thus, there is still a need for a method for discovering service layer information from management information, without relying on service information to be explicitly advertised by the network.
Thus, traditionally, discovery by a management system is limited only to discovery of network elements such as nodes, cards, ports, etc., and not network-level or services level discovery of which network components have no notion. These approaches fail to fulfill the need for an automatic service discovery approach that allows a management system to discover service MOs from the network, eliminating the need for a user or other management application to provide such information. Such a need exists in the context of management of packet voice (VoIP, VOATM) networks and metro Ethernet (TLS service) networks; however, management systems for other kinds of networks have similar needs.